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ABSTRACT 


An object-oriented simulation model is developed to 
evaluate the effectiveness of NATO Standardization Agreement 
(STANAG) 4214, which promulgates the protocol for 
international telephone call routing and directories for 
tactical communications. The model simulates communication 
systems using the STANAG 4214 1xprotocol to isolate 
disccepancies which could lead to the inability to 
successfully complete calls within the system. The model also 
simulates protocol modifications created to correct existing 
discrepancies and verifies their effectiveness in making the 
protocol more robust. Results show that these modifications 
improve STANAG call completion rate from a potential low of 
under 70 percent to 100 percent, while simultaneously easing 
the restrictions on lateral communication connections. The 
model is menu-driven with both graphical and hard copy output, 


making it useful to network planners, protocol designers, and 
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EXECUTIVE SUMMARY 


The Joint Interoperability Engineering Organization (JIEO) 
is responsible for ensuring communication systems 
interoperability with United States allies, including North 
Atlantic Treaty Organization (NATO) allies. JIEO is also 
responsible for NATO Standardization Agreements (STANAGs) and 
their implementation by the U.S., including STANAG 4214 
(STANAG 4214, 1985), which deals with international telephone 
call routing and directories for tactical communications. 

STANAG 4214 was developed to allow international routing 
between highly mobile tactical area telephone networks. The 
requirement for STANAG 4214 was established when it was 
recognized that units would be continually relocating, and 
that international forces would be distributed throughout the 
command structure. To properly route telephone calls, a 
system had to be developed that would allow unique 
identification of each unit (formation). The protocol set 
forth in STANAG 4214 was designed to meet this requirement. 

Unfortunately, several nations have had difficulty in 
interpreting STANAG 4214. These difficulties resulted in 
various attempts by some of these countries to analyze the 


effectiveness of STANAG 4214, all of which were unsuccessful. 
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These failed analyses, combined with results of international 
training exercises which revealed that the STANAG 4214 
protocol hau not been adequately tested, left JIEO with 
serious concerns about the validity of the protocol. There 
were also concerns about the strict limitation of inter-unit 
connections which could be established under STANAG 4214 
protocol. As a result of these concerns, JIEO requested the 
Operations Research Department, Naval Postgraduate School, 
Monterey, Ca, to evaluate the STANAG 4214 protocol methodology 
and to develop rules which would allow for more lenient 
guidelines on the establishment of inter-unit connections. 
JIEO also requested rules to ensure calls within a system 
utilizing STANAG 4214 protocol would not be handled more than 
once by any unit. 

To meet these objectives, an object-oriented computer 
simulation model called TACFONE-NATO was developed. The model 
is menu driven with both graphical and hard copy output. 
TACFONE-NATO incorporates all the original STANAG 4214 
protocol and allows the option of implementing several 
modifications that improve survivability of the area 
communication networks and the overall effectiveness the 
STANAG 4214. TACFONE-NATO, in conjunction with a mathematical 
program, was used to analyze the effectiveness of the STANAG 
4214 protocol, isolate discrepancies in the protocol, and to 


develop and test the rules requested by JIEO. 








The analysis revealed one discrepancy in the current 
protocol which can be remedied through a change in STANAG 
4214. The analysis also verified the need for rules which 
ensure that calls within a system are not handled more than 
once by any unit. Additionally, by using the model’s ability 
to verify modifications to the STANAG 4214 protocol, rules 
were successfully developed which ensure no multiple handling 
of calls by any unit and also allow for more leniency on the 
establishment of inter-unit connections. These rules improved 
STANAG call completion rate from a potential low of under 70 
percent (without rules to ensure multiple handling of calls by 
any units) to 100 percent, while simultaneously easing the 
restrictions on inter-unit connections. 

TACFONE-NATO will be a powerful tool used at JIEO and 
other NATO facilities. TACFONE-NATO will allow Communication 
System Network Managers of international forces to quickly 
obtain all information required to number a Communication 
System in accordance with STANAG 4214 protocol and to 
thoroughly test a proposed communication system before assets 


are dedicated to it. 
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I. INTRODUCTION 


The Joint Interoperability Engineering Organization (JIEO) 
is responsible for ensuring interoperability of communication 
systems with United States allies, including North Atlantic 
Treaty Organization (NATO) allies. JIEO is also responsible 
for NATO Standardization Agreements (STANAGs) and their 
implementation by the U.S., including STANAG 4214 (STANAG 
4214, 1985), which deals with international telephone call 
routing and directories for tactical communications. | 

STANAG 4214 was developed to allow international routing 
between mobile tactical area telephone networks. The need for 
STANAG 4214 was established when it was recognized that units 
would be not only be relocated, but also would be re- 
distributed throughout the command structure including 
attachment to other nation’s commands. In order to properly 
route telephone calls, a system had to be developed that would 
allow unique identification of each unit (formation) within 
mixed national structures. 

The result was the International Routing and Directory 
rules that are defined in STANAG 4214. Several nations, 
including the United States, have implemented the rules and 
procedures defined in the STANAG 4214. In 1987, Norway began 


the development of their Digital NATO Interface for tactical 








telephone communication systems. In their attempts to 


implement STANAG 4214, they had considerable difficulty 
interpreting the document. Several years were spent 
addressing the sections of the STANAG that could be 
potentially misconstrued. The United States held the position 
that the STANAG 4214 was generally clear, but the issues 
brought up by Norway caused some concern about the United 
States’ interpretation. 

JIEO reviewed the results of international training 
exercises to determine if there had been any problems 
encountered with the actual implementation and use of the 
STANAG 4214 protocol. It was determined from the results of 
these training exercises which utilized the STANAG 4214 
protocol, that the STANAG 4214 protocol had not been fully 
tested and validated. 

In 1991, the United Kingdom proposed modifications to the 
STANAG 4214 that would enhance area communication networks 
survivability. These proposed changes also needed to be 
evaluated to determine if they were compatible with the 
current STANAG 4214 protocol. 

At this point, JIEO determined that a study should be 
pursed to determine the actual effectiveness of the STANAG 
4214 protocol and the proposed changes. It would be difficult 
to determine the actual effectiveness of the STANAG 4214 
protocol thorough operational testing due to the size of 


communication system that it is designed to address; such a 








system would only exist if a major multi-national NATO force 
were mobilized to meet some real threat. The cost of 
establishing such a communication system for a one-time test 
would be prohibitive and would require member nations to use 
equipment that is currently utilized elsewhere. Furthermore, 
a complete and thorough testing of the rules would require 
numerous setups of various configurations. It would be 
extremely expensive in both time and assets. 

A more cost effective method of evaluating the STANAG 4214 
protocol methodology and proposed changes is computer 
simulation. A simulation model called TACFONE-NATO, was 
developed for this purpose. It is written in the object- 
oriented simulation language MODSIM (MODSIM 93). Object- 
oriented simulation means that modular blocks are used to 
emulate certain actions of physical things, these blocks of 
code are grouped together into an "object" which inherits the 
ability to perform these actions. The "object" also contains 
whatever information is required to carry out these actions. 
Object-oriented simulation was used to simulate the crucial 
elements of the communications equipment used in the telephone 
networks addressed by the STANAG 4214. The use of an object- 
oriented language made it much easier to construct an accurate 
representation of reality with this simulation. The model is 
controlled through a graphical user interface (GUI) and 


produces both graphical and hard copy output. TACFONE-NATO 


incorporates all of the original STANAG 4214 protocol and 





allows the option of implementing several modifications that 
improve survivability of the area communication networks and 
the overall effectiveness of STANAG 4214. These modifications 
developed by the authors will be discussed later. TACFONE- 
NATO can also be used by the network managers to produce the 
numbering scheme for a network, or to test a proposed 
numbering scheme that does not completely follow the STANAG 
4214 protocol. 

The interpretation of STANAG 4214 protocol used in 
developing TACFONE-NATO, the TACFONE-NATO model itself, the 
proposed changes evaluated and the results of the evaluation 
will be discussed in the following sections. The goal of this 


thesis is to develop an object-oriented simulation of the 


STANAG 4214 protocol with potential modifications, to analyze 


the effectiveness of the protocol and the modifications, and 


to make recommendations based on this analysis. 

















II. STANDARDIZATION AGREEMENT (STANAG) 4214 


In this chapter the terms necessary to discuss the STANAG 
4214 protocol will be defined to allow for concise 
understanding. The aim of the STANAG 4214 will also be 
presented. As previously discussed, there has been difficulty 
in interpreting and understanding the STANAG 4214 protocol, 
therefore the exact interpretation used in developing TACFONE- 


NATO will also be discussed in depth in this chapter. 


A. TERM DEFINITIONS 
All the terms defined below are in the context of the 
STANAG 4214. The definitions may not follow conventional 
meanings, but allow for concise understanding in the context 
of this discussion. 
1. Formations 
Any military unit that is connected in a communication 
system, as discussed below, is considered a formation. All 
formations are capable of sending and receiving calls as well 
as forwarding calls to other formations. Each formation may 
have numerous telephones within its system but is considered 


a single unit because all calls are routed through a central 


communications terminal. A formation is considered under 








command of another formation if its external communication 
needs are served by that formation. 
a. Networks 
Formations are connected into hierarchial tree 
structures called networks, see Figure 1. 
b. Host Formations 
The root of the network tree is called the Host 
Formation, see Figure 2. All formations in the network are 
served by the Host Formation’s communication system and 
therefore are under "command" (as discussed earlier) of the 
Host Formation. This communications setup may or may not 
reflect actual operational or administrative chains of 
command. 
c. Primary and Secondary Formations 
The formations directly beneath the Host Formation 
in the network with a direct connection to the Host are 
considered formations under command and are called Primary 
Formations. The formations beneath the Primary Formations are 
called Secondary Formations, see Figure 2. 
d. Communication Systems 
A group of networks connected together at the Host 
Formation level comprise what is called a Communication System 


(CommSys), see Figure =. 








Formation 


Formation 


Formation 





Figure 1 A communication network. 











Figure 2 Levels of a communication network. 


2. Connections 
a. Trunks 
The line between the formations in the Figure 4 
represents the physical connection or trunks between the 
formations. The connection can be cable, radio link, 
satellite link, or other communication links utilized by NATO 
member nations. 
b. Switches 
The switch is the physical connection point between 
a formation and a trunk, see Figure 4. There is a separate 
switch for each trunk that connects the formation to another 
formation. Each switch contains a routing table that lists 
the formations that can be reached via that trunk. The 
routing table does not necessarily reflect the physical 
connections, but rather the formations that calls are allowed 
to be routed through. By controlling the routing table lists, 
the STANAG 4214 protocol can be implemented as written as well 
as with the modifications that will be discussed in later 
sections. 
c. Gateways 
If a trunk connects formations from different 
countries, the switches on each end will contain a gateway, 
see Figure 4. The gateway converts outgoing calls from the 


formation’s national format to standard NATO format, and from 
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Formation 
Country A 


Formation 
Country A 


Figure 4 Trunk, Gateway, and Switch. 
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NATO format to the appropriate national format for incoming 
calls, see Figure 4. 
3. The Routing Prefix 

Calls are routed based on a thirteen digit number in 
NATO tactical systems as opposed to the ten digit system used 
in the United States’ commercial telephones. The number 
consists of a six digit routing prefix and seven digit local 
routing number. STANAG 4214 addresses the six digit routing 
prefix only. The routing prefix is assigned to each 


formation. It consists of two parts, see Figure 5: 


1. The first three digits are the National Indicator W), 
a three-digit code that indicates the country the formation 
belongs to. The STANAG 4214 delineates a NI for each 
nation, one for the NATO Tactical Communication System and 
two spares; 

2. The remaining three digits are the Area Code (AC), a 
three-digit code determined from the communications system 


topology, the equipment available at the formation, the 
formation’s parent and its Host. 


The routing prefix is often called a NIAC, see 
Appendix A for the complete listing form the STANAG of the ACs 
and NIs (STANAG 4214,p.B-1-2,1985). Calls are routed between 
networks using only the AC. Within a particular network 
routing of calls is based on the entire NIAC to allow 
decentralized numbering within national systems. The seven 


digit local routing number is only used within the destination 
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formation, to route a call to 
the particular subscriber 


being called. 


to 


123 4/5/6 7 @| 9 1013) 13 





Figure 5 Routing number. 


4. Calls 

A transmission generated from one formation to another 
is referred to as a call. A call can be a normal phone call, 
a modem call from one computer to another, or various other 
types of communications that can be completed over telephone 
systems. All formations under command (all except Host 
formations) must route their outgoing calls via the formation 
they are under command of (their parent), unless’ the 
destination unit is a formation under their command (one of 
their children). A call made within a nétwork is routed 
upward until it reaches a formation that is the parent or 
grandparent of the destination formation. It then is routed 
downward to the destination formation which receives the call 
and routes it to the particular seven digit local routing 
number. A call for a formation in another network will be 


routed up to the Host formation and then to the Host formation 
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of the destination formation via other Host formation(s) if 


necessary. It is then routed downward until it reaches the 
destination formation and is routed internally as previously 
discussed. 

An example of a typical call within a network follows. 
A person utilizing a telephone in a Secondary formation’s 
system calls a phone number in a Secondary formation that has 
a different Primary formation as it’s parent, see Figure 6. 
The originator’s formation system determines which switch to 
route the call through by looking at the switches’ routing 
tables for the destination formation’s NIAC. In this case 
there is only one route to the originator’s parent. The call 
is then routed through that switch and the trunk connected to 
it. The call goes through the switch at the parent’s end of 
the trunk and the parent formation’s system routes the call 
through yet another switch to the Host. The Host routes the 
call through the switch and trunk connecting him to the parent 
of the destination formation, a Primary formation in this 
case. That Primary formation then routes the call via the 
switch containing the number for the destination, and the call 
is received by the destination formation’s system. Finally, 
the call is routed to the phone with the appropriate seven 
digit local routing number. 

A call to a formation in another formation is 


different in the following ways: 
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Destination 


Originator 





Figure 6 Call internal. to network. 
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1. Once the call reaches the originator’s Host, the Host 
system determines which switch’s routing table 

contains the destination formation AC and routes it 
through that switch. 

2. The call is routed through different Host formaticn’s 


system until it reaches the Host of the Destination 
formation. 


The call is then handled as discussed in the previous example, 
see Figure 7. 
5. Equipment Capabilities 
Two equipment capabilities that are pertinent to 
formation numbering are: 


1. Whether the formation is multiple or single-routing 
capable; 


2. Whether the formation is duplicate-capable or not. 


These are discussed in the paragraphs that follow. 
a. Multiple or Single Routing-Capable 

Equipment is multiple-routing capable if it can 
route a call to another formation via multiple paths 
Simultaneously. Once the call is successfully completed along 
any of these paths, all other attempts to route the call along 
alternate paths are terminated. Since every subscriber’s 
seven digit number is unique for each country, this allows 
several formations under a multiple-routing formation to have 
the same NIAC. A call will fail only if all paths attempted 
are incorrect (not leading to the destination). On the other 


hand, equipment that is single-routing capable can only route 
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Figure 7 Call external to originator’s network. 
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a call via one path. A call routed by it through an incorrect 
path will always be a failed call. Therefore, all single- 
routing capable Hosts or primary formations require all 
formations below them to have unique NIACs. 
b. Duplicate Capable 
Equipment that is duplicate capable is able to 
route a call to another formation with the same routing prefix 


(NIAC) as its own, while not-duplicate-capable equipment 





cannot. Since the NI for all formations from one country is 
the same, formations which are not duplicate capable require 
all other formations from their nation to have unique area 


codes (ACs). 


B. AIM OF STANAG 4214 
The stated aim of the STANAG 4214 is: 


To specify the routing prefixes and their application in 
order to route calls from one tactical communications 
network to another one, from one network to the 
communications network or facilities of a unit under 
command or vice versa, and even from one communications 
network via that of a unit under command to the 
communications network or facilities of a unit under 
command of a unit under command (STANAG 4214, 1985). 


STANAG 4214 also sets forth protocol for strategic network 


interface numbering, which is not addressed by this study. 





1. Requirements for Area Codes 
As stated, the main aim of STANAG 4214 is to address 
how to allocate ACs to formations. There are 100 total ACs to 


be allocated among the NATO tactical communication systems. 
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Area Codes are assigned to networks in such a manner that all 


ACs within any individual network are different from all ACs 
in all other networks within the communication system. This 
allows the routing of calls to be based primarily on the AC 
only. Each network has a set of unique ACs to assign to the 
formations within it. Therefore, each network will be able to 
determine which calls are for it’s formations based only on 
the AC. 
2. Determination of Area Codes 
The determination of ACs is trivial if all formations 

are multiple routing and duplicate capable. In this case, a 
Single unique area code for each network is all that is 
required. However, not all nations’ communications equipment 
have these capabilities. Because of this, the STANAG 4214 
rules must address all possible combinations of equipment 
capabilities. With this in mind, the authors of STANAG 4214 
worked towards the following goals(STANAG 4214, 1985): 

1. Simplify and reduce the amount of information, in 

particular ACs, held at tne switches, and to enable 


routing on ACs alone between networks; 


2. Reduce the amount of information passed across 
networks when formation information changes; 


3. Make ACs as deducible as possible, enabling someone to 
determine the AC of a formation based on minimal 
informatic:n of the formation’s actual position in the 
communicetion system; 


4. Standardize the information passed across 
international gateways. 
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C. STANAG 4214 PROTOCOL INTERPRETATIONS 

All ACs for a network are assigned from the Host nation’s 
list of allocated Area Codes, TACFONE-NATO ignores the problem 
of exceeding the ACs of any particular nation as suggested by 
JIEO. The number of ACs assigned to a network is based on the 
communications equipment capabilities of the Host and other 
formations in the network. If a formation is from the same 
nation as it’s parent, it will receive the AC of its parent 
regardless of communications capabilities. If a formation’s 
equipment is not duplicate capable, each formation from that 
nation within the network must receive a unique AC (unless 
there are parent/child relationships as just discussed). The 
additional rules which follow apply only to duplicate capable 
formations with a different nationality than their parent 
and/or their Hosts. 

1. Host Formations 

All Host formations are assigned a Master Area Code 

that corresponds to nine minus the formation’s corps number 
followed by the last two digits of the formation’s NI. For 
example, the United States Fourth Corps would be assigned an 
AC of 514 - five (nine minus four) followed by 14(the last two 
digits of the United States NI of 914). 

2. Single-Routing Capable Hosts 

Host formations that are single-routing capable 


require unique routing prefixes (NIACs) for all Primary and 
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Secondary formations that may foreseeablely be assigned to 
them. Thus, if there are several formations from the same 
country within the network, they must all receive distinct 
ACs. Therefore, the required number of subsidiary ACs (area 
codes available to formations assigned to a Host in addition 
to the Master Area Code) is the maximum number of formations 
from any one foreign nation assigned to the network minus one. 
The example shown in Figure 8 would require the Host's master 
AC and three subsidiary ACs for a total of four because the 
NIACs will uniquely identify all formations within the 
network. 
3. Multiple Routing Capable Hosts 

Multiple routing capable Hosts only require subsidiary 
ACs if there are Primary formations within the network that 
are single-routing capable or if there is more than one 
formation from a nation whose equipment is not duplicate- 
capable. The example shown in Figure 9 would require the 
Host‘s master AC and two subsidiary ACs for a total of three. 

4. Primary Formations Under Multiple Router Hosts 

Primary formations under multiple-router Hosts are 
assigned the Host’s master area code. The only exception to 
this rule is when there are Primary formations whose 
communications equipment is not duplicate-capable. In this 
case, the first formation from a nation is assigned the Host’s 


master AC and any additional formations from that nation are 
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Germany 
AC: 814 


econdary 
France 
AC: 814 


econdary 
France 
AC: 816 


econdary 
France 
AC: 214 





Figure 8 Single-routing capable Host. 
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Multiple Route 
Host Germany 
AC: 804 


Single Houter Multiple Route 
Primary UK Hrimary Germany 
AC: 804 AC: 804 


econad ary BCONnG ary 
France Denmark 
AC: 804 AC: 804 


econd ary BCONG ary 
France Denmark 
AC: 819 AC: 804 


econdary econdary 
France Germany 
AC: 204 AC: 804 





Figure 9 Multiple-routing capable Host with a single-router 
Primary. 
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assigned distinct ACs. The example in Figure 10 shows a 
network with a multiple-router Host with all duplicate-capable 
Primaries, therefore, requiring only the master AC. The 
example in Figure 11 shows a network with a multiple-router 
Host with two Primaries that are not duplicate-capable and 
from the same country, therefore, requiring the Host’s master 
AC and one subsidiary AC. 
5. Primary Formations Under Single Router Hosts 

The first Primary formation from each nation under a 
single-router Host is assigned the Host fo:mation’s master AC. 
Additional formations from the same nation will be assigned 
unique subsidiary ACs from the list allocated to the Host 
nation, see Figure 8 for an example. 

6. Secondary Formations 

Area codes for Secondary formations are dependent on 
the communications equipment characteristics of the Host 
formation, its Primary (topologically parent) formation and 
the formation itself. 

a. Host Formation and Primary Formation are Both 

Multiple Routing Capable 
A Secondary formation with its Host formation and 

Primary formation both multiple-routing capable is assigned 


the AC of its Primary formation, see Figure 12 for an example. 
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Multiple Route 
Host France 
AC: 803 


Duplicate Capable Duplicate Capable 
Germany Primary Sermany Primar 
AC: 80 AC: 803 


AC: 803 


Secondary 
AC: 803 


Secondary 





Figure 10 Multiple-routing capable Host with all Primaries 
duplicate-capable. 
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Multiple Route 
Host Germany 
AC: 704 


Not Duplicate Not Duplicate 
Capable Canad Sapable Canad 
Arimary AC : 70 Rrimary AC: 71 


Figure 11 Multiple-routing Host with two not duplicate- 
capable Primaries. 
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Multiple Route 
Host Belgium 
AC: 800 


Multiple Route Multiple Route 
Primary France Primary Germany 
AC: 800 AC: 800 


Secondary 
AC: 800 


Secondary 
AC : 800 

Secondary Secondary 
AC: 800 AC: 800 





Figure 12 Multiple-routing Host with multiple-routing 
Primaries 
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b. Host Formation and/or Primary Formation are Single 
Routing Capable 
A Secondary formation whose Host is multiple- 
routing capable but whose Primary is only single-routing 
capable must receive an area code which is unique from all 
other formations of the same nation under that particular 
Primary. As previously stated, a Secondary formation whose 
Host formation is only single-routing capable is assigned a 
unique AC from all other formations from the same nation in 
the Host’s network, see Figure 8. 
7. Other Rules 
In addition to the above listed rules, STANAG 4214 
also directs that each Host formation be assigned three 
subsidiary ACs regardless of the formations used to make up 
the network. This added rule is not reflected by the TACFONE- 
NATO model because the numbering method created for TACFONE- 
NATO determines the exact number of subsidiary ACs needed for 
each network. Also, the STANAG protocol allows an option 
whereby a single-router Host with a multiple-router Primary 
may assign all Secondary formations of that Primary the same 
AC if there is no possibility of them moving up to the Primary 
level. In authors’ view, due to the dynamic force structures 
involved the requirement for this option cannot necessarily be 


guaranteed, so this option was not considered or utilized in 


this study. 





D. SUMMARY 

The terminology introduced in this chapter will allow for 
more concise discussion in this and following chapters. The 
protocol interpretation presented in this chapter gives a 
plain language version of the complicated set of rules laid 
out in the STANAG 4214. As can be seen from the discussion of 
the protocol, there are numerous situations that can arise in 
the configuration of communication systems and therefore an 


extensive set of rules is required to cover all contingencies. 


The complexity of the rules makes the task of modeling the 


protocol much more difficult, as will be discussed in the 


following chapter. 











III. MODELING THE NATO COMMUNICATION SYSTEM 


The problem of modeling the NATO communication system and 
the process generating and routing all possible calls is very 
large and complex. Because the system is composed of 
independent pieces of equipment whose functions can be 
emulated, it lends itself to being modeled and analyzed 
utilizing an object-oriented simulation language. 
Accordingly, the TACFONE-NATO model was written in object- 
oriented modeling and simulation language MODSIM (MODSIM 93). 
TACFONE-NATO simulates a communication system’s' crucial 
elements in order to allow the implementation of the STANAG 
4214 protocols. The entire model was designed to represent 
the physical equipment and the actual process of sending and 
receiving calls, but only at the level of fidelity for each 
element that was required for this study. Therefore, some 
elements that are modeled may not exactly reflect the actual 
equipment or process simulated, but for the purposes of the 
study reflect accurately the portion that affects numbering 
formations and routing calls. The model is completely 
supported with graphics, which promotes ease of use and 


Simplifies the analysis of results. 
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A. Basic Model Objects 

A description of the basic building blocks of TACFONE-NATO 
follows. They simulate the crucial elements of a 
communication system that are required to evaluate the STANAG 
4214 protocol. 

1. Communication System 

A communication system consists of a set of networks, 

inter-connected only through their Host formations. These 
interconnections create at least a minimally connected graph 
of all networks (Figure 13) and may create up to a fully 
connected graph (Figure 14). 

2. Networks 

A network is a hierarchically constructed tree of 

formations with a maximum of three levels, this is the maximum 
number of levels the STANAG 4214 protocol addresses. The only 
connections allowed between formations in a network are the 
ones that follow this tree structure. Therefore, the 
Secondary formations only have one connection, with their 
parent (Primary) formation. The Primary formations have one 
connection with each of their children (Secondaries) and one 
connection with their Host formation. Each Host formation has 
one connection with each of his child Primary formations and 
connections to other Host formations, depending on the 


topology of the communication system. 
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Figure 13 Minimally connected graph. 
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Host Formation 





Figure 14 Fully connected graph. 
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3. Formations 
The formations represent the communication systems of 
different sized military units. Generally, Host level 
formations represent Corps-sized units, Primary level 
formations equate to division-sized units and Secondary level 
formations represent brigade-sized units. The STANAG 4214 
protocol does not address units of any smaller size, 
therefore, TACFONE-NATO does not represent any other unit 
types. 
4. Switches, Trunks and Gateways 
The function of gateways are not crucial to the 
routing protocol addressed by STANAG 4214 and therefore are 
not modeled. The switches and trunks are modeled to reflect 
previously discussed definitions. The switches are the 
connection between the formation and the trunk and contain the 
routing information for that path from/to the formation. The 


trunk connects two formations and routes calls between them. 


B. NUMBERING THE COMMUNICATIONS SYSTEM 

The model numbers the Communication System according to 
the rules of STANAG 4214 previously discussed. Each formation 
numbers itself, by de*ermining its own, its parent’s and its 
Host’s communication equipment capabilities and applying the 


applicable STANAG 4214 rule(s) for its numbering. 
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C. GENERATION OF COMMUNICATION SYSTEMS 


TACFONE-NATO will either read in a user-defined force 
structure or randomly generate a force structure. If the 
force is user-defined, TACFONE-NATO can automatically number 
the communication system or the NIACs can be defined by the 
user and analyzed using TACFONE-NATO. This gives the user the 
flexibility of analyzing a proposed numbering scheme that does 
not follow the STANAG rules. The connections between networks 
at the Host level are either randomly generated by TACFONE- 
NATO or defined by the user. When the communication system is 
generated randomly, the number of networks, formations and 
connections between networks are all randomly determined from 
preset bounds. The identity of the formations, including 
nationality, are also randomly determined from the existing 
units that are available to NATO. 

The units available from NATO are determined from the 
table in the STANAG 4214 (STANAG 4214, p. B-1-2, 1985), see 
Appendix A. The model starts with this force allocation as it 
randomly generates a force structure and will not exceed the 
number of Host formations, three Primary units for each Host, 
and three Secondaries for each Primary listed in the table. 
Once the force has been generated and connected, the 


formations are numbered using the method previously discussed. 
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D. BUILDING ROUTING TABLES 


Once the communication system is generated and has been 
numbered, the routing tables are initialized for each trunk of 
each formation. Each network first updates its routing tables 
internally, then the switches connecting the networks 
initialize their routing tables. The basic model cllows all 
paths that exist from one network to another to be reflected 
in the routing tables. STANAG 4214 does not directly address 
what paths should exist from one network to another, only that 
it is done in a way "to prevent looping" (STANAG 4214, p. c-2, 
1985). The basic model operates this way to provide the 
ability to measure the effectiveness of anti-looping rules, 


some of which will be discussed below. 


E. GENERATING AND ROUTING CALLS 

Calls are generated from every formation to every other 
formation. The formation routes a call based on the physical 
limitations of the communications equipment of its nation, as 
well as the contents of its switches’ routing tables. Between 
networks, calls are only routed via one path (single-routed). 
The call tracks all formations that it is routed through to 
reach its destination. There are several circumstances where 
a call fails to reach its destination, each creating a unique 
diagnostic problem. These circumstances will be discussed 


later. 
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F. GRAPHICS 

The TACFONE-NATO model utilizes the SIMGRAPHICS (MODSIM 
93) portion of MODSIM to display all input aid output 
graphically. The model is controlled through mouse-driven 
graphical user interfaces making it quite user-friendly, 
compared to all input being entered through the keyboard. The 
Communication System is displayed graphically using a separate 
window for each network. Each formation is displayed as a 
rectangle enclosing its nationality, unit size (corps, 
division, or brigade), unit number, and NIAC. Trunks are 
represented as lines between formations,see Figure 15 for an 
example of a network representation. The set of Host 
formations are also displayed in a separate window, with 
inter-host connections displayed as lines, see Figure 16. As 
each call is routed, the originator formation, the destination 
formation, and all trunks in the path are colored to allow the 
user to visually watch the calls progress. The display is 
frozen when a call fails, which aids in trouble shooting 


protocol problems. 


G. SUMMARY 

TACFONE-NATO as presented in this chapter is an object- 
oriented computer model which simulates the STANAG 4214 
protocol, calls, and all equipment required to effectively 
evaluate the protocol. The model is GUI driven and user- 


friendly. Complete instructions and more extensive 
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Figure 15 A network representation. 








explanations of the use of the model is given in the user's 


manual in Appendix B. 
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Iv. CAPABILITIES ADDED TO THE BASIC MODEL 


JIEO was very interested in the development of anti- 
looping rules and in exploring the effects of allowing lateral 
connections. In this chapter these critical issues will be 
defined and some proposed techniques for dealing them will be 


discussed. 


A. Anti-Looping 

STANAG 4214 explicitly states that routing tables between 
the Host formations must "not allow loops to exist" (STANAG 
4214, p. C-2, 1985 ). A loop occurs when a call arrives at a 
formation which has already handled it. Figure 17 depicts 
routing tables which provide the possibility of a loop. Here, 
Host five initiates a call to Host one, selecting to route the 
call through Host three, who in turn routes it through Host 
two. At this point, Host two’s routing tables allow him to 
either route the call to Host one or through Host five. If 
the route through Host five is selected, a loop occurs since 
Host five has already handled the call. The bold path in 
Figure 17 illustrates this occurrence. While the STANAG 
states not to allow loops, it does not provide any methods of 


doing so. Here, rules are developed for building routing 
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Figure 17 A looped call. 
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tables between Host formations which ensure that looped calls 
are not possible. 
1. Objectives of the Rules 

A simple solution to the problem would be to build the 
routing tables such that there was only one path from each 
Host to all others. While this would certainly avoid looping, 
it is not particularly desirable because it removes all 
possible redundancy which the physical system may be able to 
support. Of course, the more redundancy allowed, the greater 
the potential for creating the possibility of a loop. In 
light of this, rules were sought to build routing tables such 
that: 


1. There exists at least one path from each Host to every 
other Host. 


2. There is no potential for a looped call. 


3. Maximum redundancy is achieved under the following 
constraints: 


a. Maximize the minimum number of switches through which 
a Host can route to any other Host. That is, for a six 
Host Communication System, it is preferred for a Host to 
be able to route to all other Hcsts through two switches 
rather than to be able to route to three Hosts through 
five switches, but to the other two through only one. 
The goal is to "spread the wealth" for redundancy. 


b. Shorter paths are sought for redundancy before longer 


ones. That is, it is more desirable to have a three step 
path than a four step path between two Hosts. 
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2. Proposed Solution Techniques 
a. Complete Enumeration 

Since the number of Hosts being dealt with was 
fairly small (a maximum of six), an attempt was made to fully 
enumerate the various combinations of routing tables possible 
and compare them. To ensure this would be feasible for all 
Communication Systems which could be constructed with six or 
fewer Hosts, the worst-case scenario of having six Hosts, each 
connected to every other Host was considered. In this 
situation there are a total of 30 routing tables to fill, each 
of which may contain any or all of five different numbers. 
Assuming that each routing table will contain the Host number 
to which it is connected, four spaces are left in each routing 
table which may or may not contain a number. With a total of 
30 tables, this leaves 120 unique spaces with a go/no-go 
decision as to whether to or not to put in a number. This 
results in a total of 2??° (equals approximately 1.33 x 10%*) 
possible routing table combinations. If it were possible to 
fully examine one trillion of these possibilities every 
second, it would take over four hundred trillion years to 
examine each possible combination of routing tables. This is 
obviously infeasible. 

b. Anti-Looping Heuristic 
Since it is infeasible to fully enumerate all 


possible routing table combinations for all Communication 


44 








Systems which could be constructed, and because the problem 


does not formulate neatly as an optimal-solved mathematical 
program, a heuristic was developed to meet the previously 
stated goals. The steps of the heuristic are: 


1. For each Host switch which connects to another Host, 
enumerate all possible non-looping paths to all other Hosts 
based on the physical structure of the inter-host 
connections (an inter-host connection is a connection 
between two different Hosts). 


2. For each inter-host switch, add the connected Host to 
that switch’s routing table. 


3. start with any inter-host switch. From all possible 
two-step paths, choose the one whose destination is in the 
fewest routing tables of the switch’s formation. If a tie 
exists, randomly select from those tied. If no two step 
path exists, move on to step (5). 


4. Check to see if adding this destination to the switch’s 
routing table will cause a loop based on the destinations 
currently in °*1l the other inter-host switches’ routing 
tables. If wot, add the destination to the switch’s 
routing table. If it does cause a loop, remove this path 
from all possible two step paths and repeat step (3). 


5. Repeat steps 3-4 for each inter-host switch. 


6. Repeat steps 3-5 until all possible two step paths 
have been examined to see if they cause a loop. 


ie Repeat steps 3-6 for all possible three step paths, 
then for all possible four step paths,..., and finally for 


all possible (n-1) step paths; where n is the number of 
Hosts in the Communications System. 


NOTE: When conducting step (3) for paths of three or more 

steps, ignore all paths whose destination is already in the 
switch’s routing table. 

Only paths of length (n-1) or shorter need be 

examined since any lenger path would necessarily form a loop. 


Checkirg all paths up to length (n-1) ensures that in the 
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worst case of only a (n-1) step path existing between two 
Hosts, they will still be able to reach each other. In fact, 
a more in-depth check of this algorithm shows that, assuming 
at least a minimum spanning tree is formed by the inter-host 
connections, each Host will be able to reach every other Host. 
This can be shown by assuming Host j cannot reach Host k with 
at least one non-looping path. This would imply that none of 
the Hosts connected to Host j could reach Host k with a non- 
looping path, since if one could, a non-looping path from j 
could be formed by adding the link from j to the Host which 
could reach k. By inductively continuing in this manner, it 
can be shown that if Host j cannot reach Host k by a non- 
looping path, then no Host in the Communication System can. 
But this is not possible since k is connected to a least one 
other Host in the Communication System. Therefore, it is not 
possible for Host j not to be able to reach Host k with at 
least one non-looping path. Since this applies to any two 
Hosts, each Host will be able to reach every other Host. 

It is also clear that this heuristic ensures 
that no loops will exist since this is checked prior to adding 
any number to a routing table. Furthermore, the selection 
process in step (3) of the heuristic is conducive to 
Maximizing the minimum number of switches through which a Host 
can route to any other Host. The iterative process of 


checking for the smallest-step paths first also contributes to 
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including shorter paths before longer ones. Thus, the 


heuristic promotes all of the stated goals. 


B. Lateral Connections 
The STANAG 4214 protocol does not allow for connections 
between units other than parents and children and between 
Hosts. Any connection established between units other than 
between Hosts or between a parent and child is defined as a 
lateral connection. The reason STANAG 4214 does not allow 
lateral connections is the increased risk of looped calls. 
However, units not connected under current STANAG 4214 
protocol may be in close physical proximity, and it may be 
very desirable for these units to have a communications link 
between them for local lcgistical traffic. The current STANAG 
4214 protocol does not allow for such a link. Here, routing 
table rules are developed that allow for lateral connections 
to be established without resulting in possible loops. 
1. Recommended Rules 
Rules were desired which would cover any possible 
lateral connection. That is, Primary to Primary, Secondary to 
Secondary, Host to a non-child Primary, Host to Secondary, and 
Primary to a non-child Secondary. Furthermore, it was desired 
for the rules to work whether the lateral connection existed 
between formations within the same network or between 
formation in different networks. Additionally, it was 


undesirable for the rules to in any way restrict the number of 














lateral connections allowed as this would become very 
confusing. 


The rules developed to meet these requirements are as 


follows: 
Ls No call shall be allowed to route downwards in a 
network’s hierarchical structure to make use of a lateral 
connection. 
23 No call, after using a lateral connection shall be 
allowed to route upwards in a network's hierarchical 
structure. 


3. No call shall be routed through more than one lateral 
connection. 


In TACFONE-NATO, these rules are enforced through the 
construction of the routing tables, as opposed to each call 
tracking its use of lateral connections. Because of this, if 
there are more than two formations from any nation in a 
network which are numbered the same (implies that the Host is 
multiple-routing and the nation is duplicate-capable), and anv 
two of these are laterally connected, the above rules may be 
violated. However, even with this feasible "breaking of the 
rules", there will be no looping. The only possibility of 
looping when routing tables are used to enforce these rules is 
if four.or more formations from a single-routing nation are 
numbered the same and are laterally connected in such a manner 
as to allow looping via the lateral connections alone. This 
means that for there to be a problem with the enforcement of 
these rules through routing table construction, all of the 


following must occur: 
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1. Multiple-routing Host. 

2. Four or more formations from a _ single-routing, 
duplicate-capable nation in the network be numbered the 
same. 

3. The existence of enough lateral connections between 
these formations such that the lateral connections 
themselves provide the possibility of a loop. 

The existence of this unique set of circumstances 
would is highly improbable and would rarely, if ever, be 
realized in an actual Communication System. Therefore, in the 
opinion of the authors, enforcing the previously stated rules 
through routing table construction is valid for ail 
Communication Systems which may reasonably be assembled. 

These rules somewhat localize the use of lateral 
connections, but this is not unreasonable since it is likely 
that the main purpose for establishing a lateral connection 
would be for local traffic between two formations not 
otherwise connected. These rules do prevent looping (with the 
exception of the improbable unique case stated above) for any 
number of any type of lateral connections and also provide for 


maximum additional redundancy without putting restrictions on 


the number of or types of lateral connections allowed. 


C. SUMMARY 

Two of the issues of greatest concern to JIEO were anti- 
looping rules and the effects of lateral connections. This 
chapter presented the methods used to develop anti-looping 


rules and routing table rules which allow for lateral 
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connections. TACFONE-NATO always implements the lateral 
connection rules (if no lateral connections exist they have no 
impact) and allows for the option of implementing the anti- 


looping rules. 
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V. DEDUCING ERRORS IN THE PROTOCOL 


The heart of the analysis of the STANAG 4214 protocol lies 
in determining the overall effectiveness of the protocol and 
in detecting and isolating errors in the protocol. This 
chapter discusses the methodology employed to accomplish these 


tasks. 


A. ANALYSIS FOR A SINGLE COMMUNICATIONS SYSTEM 
The basic procedure executed by TACFONE-NATO is as 
follows: 


7. Construct a reasonable force composition for the 
operation, choosing: 


a. Country 
b. Level of unit 
c. Unit capabilities 


2. Construct a reasonable NATO chain of command for this 
force. 


zim Construct a reasonable set of physical connections 
between pairs of units. 


4. Assign telephone numbers to each of the formations. 


5. Construct the proper routing table associated with each 
switch in each formation. 


6. Attempt a call from each formation to every other 
formation, recording the outcome. 


This procedure will be henceforth known as a single-system 


check. Note that there is a one-time construction of the NATO 
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force structure, and one assignment of nationality for each 
formation in a single-system check. TACFONE-NATO allows for 
a single run of the single-system check or for the single- 
system check to be executed over and over, using the ability 
to sample random variates to generate different force 


structures and nationalities for each check. 


B. ANALYSIS OF OVERALL EFFECTIVENESS 

Determining the overall effectiveness of the STANAG 4214 
protocol does not require knowledge of how many potential 
failures may occur in the protocol under various 
circumstances. It does not even require knowledge of what the 
causes of any failure are. This is because the number and 
type of feasible failures does not take into account the 
likelihood that situations which cause these failures would 
actually exist in a communication system. Furthermore, just 
because a path exists in the routing tables which leads to a 
failure does not mean that a call will always take that path. 
Indeed, actual calls may rarely follow paths which lead to 
failures. Because of this, the measure of effectiveness 
developed for the STANAG 4214 protocol was the mean percentage 
of successfully completed calls when each formation called 
every other formation once in a random communication system. 

To determine a good estimate of the mean percentage of 
successfully completed calls for a random communication system 


using the STANAG protocol, the following procedure was use: 
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1. Generate a random Communications System 


2. Make a good estimate** of the mean number of successful 
call for that communications system when each formation 
calls every other formation once, with each call following 
only one feasible path (when more than one feasible path 
exists randomly choose one of them). 


3. Record the estimated mean number of successful calls. 
4. Iterate until enough estimated means from different 
communication systems have been collected to build a 95% 
Confidence Interval for the grand mean whose bounds are 
within ten percent of the estimated grand mean. Ensure 
that a minimum of 30 Communication Systems are used for the 
normality assumption. 

**To determine a "good estimate" for a single Communication 
System: make all calls and determine the percent 
successful; repeat until enough data points have been 
collected to build a 95% Confidence Interval whose bounds 
are within ten percent of the estimated mean percent of 
successful calls for that Communications System; ensuring 


that at least 30 samples are collected for the normality 
assumption. 


Additionally, all of the data points used to build the 
above estimates were collected for comparisons of high and low 
percentages of calls successful. This provided some insight 
of the variability of the protocol’s success rate on various 


communication systems. 


C. GRAPHICAL CAUSE IDENTIFICATION 

To completely validate the protocol, all causes of any 
possible failure must be isolated. The simplest way to 
isolate the cause of detected failures is by using the 
graphical display developed for TACFONE-NATO. TACFONE-NATO’s 


graphical display provides a usable problem diagnosis tool 














which allows users to employ their intuition to identify 
failure causes. 

A method for generating failed call displays was developed 
to show a graphical representation of failed calls on screen. 
The display, which continually shows the calls being routed, 
freezes when an attempted call fails. The originator, path, 
and intended destination light up in unique colors so they can 
easily be identified. By analyzing the characteristics of the 
formations involved, it may be possible to intuitively deduce 
what the problem is. This tool proved to be of tremendous 
value for both debugging TACFONE-NATO and in helping to 


identify problem areas in the STANAG 4214 protocol. 


D. ISOLATING CAUSES FOR FAILURES 

When a large number of failures exist, it is impractical 
to attempt to intuitively determine all the causes of failure 
using the graphical display. Even when only a small number of 
failures occur, intuition may fail to yield a cause for 
failures. To assist in isolating causes for failures in these 
cases, a mathematical program was developed to single out the 
most likely set(s) of circumstances which lead to failures. 
The development of this program will now be discussed. 

1. Possible Outcomes and Assignable Causes for Errors 

Each call can experience one of three outcomes: 


1. Be complete as specified. 
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2. Arrive at a formation which has already handled the 
call (loop). 


3. Arrive at a formation which has no way of reaching the 

destination (dead-end). 
Each simulated call n involved had an originating formation 
f,.., and a destination formation f,,. Each call could have 
many feasible paths based on the routing tables. Each of 
these feasible paths will be referred to as an attempt for 
call n. To validate the protocol and routing table entries, 
all feasible paths must be examined. Therefore, each call is 
repeated until all feasible paths have been examined. Each 
attempt records its journey through the network, building f,, 
= (f,0, Enis +--+ Fue), where f,. is the it formation relaying 
attempt m. If the attempt is completed, f,. = fna- 


Now record: 


1 if attempt is successful; 
Xx" = 2 if attempt loops; 


3 if attempt dead~ends. 


The path f£, and the value of X indicate where the trouble- 
causing switches are (i.e., routing tables at these switches 
may be causing looping or dead-ends). Table 1 shows some 


prime suspects for different completion outcomes. 
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TABLE 1 LIKELY CAUSES FOR FAILED CALLS 











I 


lox | Prime Suspects 


i fey fo oe 














loop includes 
outgoing switch should omit at least one entry 


.,f, = £,), at least one 





| 
i 
[ 
3 f,., switch overstates formations reachable 
f,,, switch overstates formations reachable 
f, has at least one switch which has an omission 


| | 
| 2 or 3 | f, numbered incorrectly 


The prime suspects for each type of failure can now be 
examined to attempt to determine which formation 
characteristics, as defined in the next section, the STANAG 
4214 protocol has trouble in handling. 
2. ANALYZING ERROR DATA 

The objective of this part of the analysis is to 
determine the causes of incomplete calls (attempts). 
Incomplete calls arise because of one or mo. = mistakes in the 
formation of the routing tables in the switches, or in 
ambiguous or incorrect formation area code assignments. Each 
formation has key characteristics which determine the method 
used to assign its area code (number the formation) and the 
manner in which it forms its routing tables. 
The key characteristics of any formation are: 

1. ROLE: Host(H), Primary(P), or Secondary(S) ; 


2. NATV: true(T) if native to (same nationality as) 
parent, false(F) if not; 
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3. DUP: true(T) if duplicate-capable, false(F) if not; 


4. HRT: single-routing(S) if Host is single-routing, 
multiple-routing(M) if Host is multiple-routing; 


5. PRT : single-routing(S) if Parent is single-routing, 
multiple-routing(M) if Parent is multiple- routing. 

Each failed call is caused by some shortcoming of the 
numbering rules or routing tables which arise from some 
combination of these characteristics. For exanple, it is 
possible, albeit improbable, that something is wrong with Lhe 
rule for numbering any Secondary formation. It is also 
possibie that secondary formations which have nationalities 
which are different from their parent, and whose parent is 
multiple-routing, are not all numbered correctly. The 
objective of the analysis is to distinguish the precise 
combination of characteristics under which calls are not 
reliably routed to a formation. 

3. ALGORITHMIC CAUSE IDENTIFICATION 

It is reasonable to assume that the "most common" kev 
characteristics for likely suspect formations of failed 
attempts are the most probable to be those which the STANAG 
4214 protocol has difficulty handling. This makes it 
desirable to determine which are the "most common" 
characteristics for likely suspects of failed attempts. 
Visual inspection of output files would be one way to do this, 
but for a large number of failed attempts, this would be very 


tedious and time consuming. Therefore, a mathematical 
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program was developed to aid in finding the “most common" key 
characteristics of a set of likely suspects. 
For each failed attempt m, collect the likely suspects 


for attempt m in accordance with Table 1. Now let 


1 if a prime suspect formation for 
attempt m has properties ROLE, 
NATV,DUP, HRT, and PRT 


@"ROLE,NATV, DUP, HRT, PRT = : ; ; 
O if the combination ROLE, NATV 


DUP,HRT, and PRT does not describe 
a prime suspect for attempt m 


Let a@nos,.,...... be a similar indicator variable for the 

ROLE of each prime suspect for attempt m, with a" wyw,..... Z 
@noue,..vuP..,./ @RoLE.natv,.,.,prtr @tc., similarly defined. For 
example, if the only likely suspect for failed attempt one was 
a duplicate-capable, Secondary formation from the same country 


as its Primary, with both its Host and Primary formations 


multiple-routing, then the following a’’s would be assigned 


the value of one: Qsrarume  @s.t,tM,.6 4 s.t.7,..m0 2's,7,..MMe 
a's. tM Ms a tt MM a sin.t,.,.1 @’s.c, Moe Q’s.t,.,.me @'s,..0.m,.1 @s,..0,..m0 
a's. MMe @ oaem,.: @oat,.me 2 ot, 2 tm 4's.2,.,.,.7 4s, ..0, 2,08 
as, ....M,.4 a's, Sch Ms Ce Dot miit @ ot,....Me a’ one. a eT 
a MMe Boi stsen ae ee Bn es bt A uy PAs The 


a’’s representing all other characteristic combinations would 
be zero. 
Now let Zgore,narv.pup.urt.prr DE a Similarly indexed decision 


variable with values as follows: 
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1 if problems arise in 
implementing STANAG 4214 for 
formations with properties 
ROLE, NATV, DUP, HRT, and PRT; 


ZRoLE,NATV,DUP,HRT,PRT = . : ; 
0 if formations with 


properties ROLE, NATV, DUP, 

HRT, and PRT are handled 

correctly. 
shese variables will be referred to as cause conclusion 
indicators. If one conclusion is a refinement of another 
(e.g., H,.,.,S,S is a refinement of H,.,.,.,.), the more 
general conclusion indicator is referred to as a composite 
conclusion, while the refinement is a constituent conclusion 
of the more general one. These variables will be used ina 
simple set-covering-like optimization which will have as its 
solution the likely set of causes (the ones which occurred 
most frequently) for the given set of failed attempts. Since 
it is reasonable that the two different types of failures 
(loops and dead-ends) would be caused by different problems, 
the sets of likely suspects will be grouped by the type of 
failure they were a suspect for. The optimization problem 
will be solved for each of these groups separately. 


Consider the following mathematical program constraint 


set: 
m 
1< > ZROLE, NATV, DUP, HRT, PRT @ROLE, NATV, DUP, HRT, PRT + Um (1) 


for each failed attempt m, where Q is the set of all possible 
combinations ROLE, NATV, DUP, HRT, PRT with ROLE € {H, P, S}, 


NATV € {T, F}, DUP € {T, F}, HRT € {S, M}, and PRT € {S, mM}. 
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The u, corresponds to not being able to assign a cause to 
failure m. By convention, this is called a zero-factor 
conclusion. This set of constraints will produce a 
combination of z's and u’s which cover all of the failed 
attempts. That is, for each failed attempt m, either u, is 
selected or at least one of failed attempt m’s likely suspects 
has the characteristics defined by at least one of the 2's 


selected. Furthermore, it is preferred to have information 


which is as precise as possible; accepting z,.. as one is 
less desirable than accepting z,,7,,..,. which, in turn, is 
less desirable than accepting 2,775.5. The objective is to 


produce a set of decision variables which give as much 
information as possible. On the other hand, if 2445.5, 
Zp.t.1,5,s) and Zg77,5,5 are all one, what really exists is a 
situation where they should all be zero, and 2 77,55 should be 
one. A set of costs will now be constructed, along with some 
more constraints so that the program produces a set of 
indicated causes which are both parsimonious and precise. 
Let the number of constituent conclusions for each 
conclusion variable be counted and denoted by Mpyore nar, pup. arr, PRT* 
By definition, let Mgore nar,pup.urtr.prt = 12 for all five-factor 


indicators. Then 


1 warv,pup, HRT, PRT = 2y, atv, DUP, HRT, PRT 
+ MQp narv, pup, HRT, PRT 
+ Dg warv, DUP, HRT, PRT 
3 


because the first factor has three states. Similarly, 
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Dgove, ., pup,HRT,pRT = 2 


because the second factor has only two states. That is, a 
four-factor n equals the number of options for the missing 


factor. Continuing in this manner, one can show 


Poe, NATV,.,.,. 
= Deore,natv.t,.,. + MRroze,natv.F,.,. 
= Mpore,natv,.,s,. + PRoie,NaTV,..M,. 


= Mpore,natv,.,..S + NRore,Natv,.,., M 


= 8, 


and so forth. 

The basic cost structure is now constructed so that 
the cost of concluding a four-factor conclusion variable is 
true is slightly larger than the cost of proclaiming that all 
of the constituent conclusions are true. This will promote 
specificity. Continuing in this spirit, conclusions with less 
factors will be made just slightly more costly than all of the 


constituent conclusions. To accomplish this let 


Dros, NATV, DUP, HRT, PRT = TROLE, NATV, DUP, HRT, PRT + 0.01 


be the basic cost of concluding 2Zgoe narv,pup,urt,prr GQuals one. 
While this basic cost structure will result in 
determining the most specific characteristics for the likely 


suspects, it does not guarantee that the most common 
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characteristics will be identified. Consider a group of 
likely suspects for a failed attempt with all but one of the 
suspects having identical five-factor characteristics. Both 
of the feasible five-factor conclusion variables have the same 
positive cost and both would cover the failed attempt. Since 
the goal is to minimize cost, the mathematical program will 
only allow one of the conclusion variables to take on the 
value one. Since each of the conclusion variables have the 
Same cost under the basic cost structure, the mathematical 
program would be just as happy to chose the lone suspect's 
five-factor conclusion as the five-factor conclusion of all 
the other suspects. In order to give more weight to 
conclusions which appear more frequently, the final cost for 


a particular conclusion is made as follows: 


CRoLe, NATV, DUP, HRT, PRT = Pgoue, atv, pup, HRT, prT/ CRoLE, NATV, DUP, HRT, PRT 


Where  trore narv.pup.Hrt,prT. 21S the maximum of one and the total 
number of all likely suspects with the given n-fold factor 
conclusion. 

Recall that if all of the five-factor constituent 
conclusions are chosen for some four-factor conclusion, it is 
desired to force the choice of the four-factor conclusion 
instead. To ensure that conclusions with less factors are 
chosen when appropriate, the following constraint set must be 


added to the mathematical program: 
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4u,17,1,8,s + 2p,t.t.s,s 


N_s+,t,s,s%.,7,7,5,8 = 
+ 2s 27s.s - (Miz2,5,5 - 1) (2) 


Nn soit,t,s,m2.,7,7,5,M 2 2y,7,7,5.m + 2p,t,t,s.m 





+ 2sc.rsu 7 (2og2,s.0 7- 1) (3) 
Dy,t,r,.,.2n,7,F,.,. 2 Wu.t.p,s,.2n,17,7,s,. + Yu,t,e,m,.2n,7,F.m,. 

- (Mare,.,. - 2) (4) 
Dyt.r,.,.2n,7.F,.,. = Pn.t.r,.,s%n,7,p,.,s + Mn,t.r,..mZH,1,P,..m 

- (Myer... - 21) (5) 
Dy, .je,.,.2n,.,F,.,. 2 Yu rir,.,.%n.7,7,.,. + Dn r.r,...2H,F,F,.,. ; 

- (myor,.,. - 1) (6) 
My, ..e,.,.2H,..F,.,. 2 n,.,F,s,.4H,.,r,8,. + Pu, pim,.2H,.,FM.. 

- (pyr... 7 2) (7) 
Oy, .ie,.,.2H,.,F,.,. 2 Un,..F,.,s7H,.,r,.,¢ + Dn,.,.¢,..m2n,.,F,..M 

- (My or... = 1) (8) 
My, ...,.%H,.,...,. = Unt,.,.,.2n7,.,.,. + Onp,.,.,. 20 r,.,.,. 

Saif renee ae 2 (9) 
Nyy, 2n,.,.,.,. 2 Un,.,7,.,.4%H,.,7,.,. + On,.,p,.,.%n,.,P,.,. 

a. ewe (10) > 
Dy... 4H,.,.,... = Mn,.,.,8,.2%H,.,.,8,. + On,.,..m,.FH,.,.0m,. 

ec: 0) (2) 
My, .,.,.,.4H,...,.,. 2 Tn,.,., ,s!H..,.,.,8 + n,.,.,..M%H,.,.,..m 

= (ny . 2a Oe 1) (12) 


A check of these constraints shows that if the program selects 
an entire set of constituent conclusions, the composite 
conclusion is chosen as well. However, since there would then 
be a redundancy, the cost structure will ensure that the 


constituent conclusions will be dropped when possible. Thus, 








by combining the set-covering constraints (Equation 1) with 


forced composite constraints (Equations 2-12), the feasible 
region of a mathematical program is defined. The objective 


function, given as 


min » CROLE, NATV, DUP, HRT, PRT“ ROLE, NATV, DUP, HRT, PRT * > Coles. Un 


where Q is defined as before and t is the total number of 
failed attempts, completes the specification of the 
mathematical program. This optimization is solved using some 
of the methods found in Balas (1980) and the General Algebraic 


Modeling System (GAMS) software package. 


E. ANALYSIS OF MULTIPLE COMMUNICATIONS SYSTEMS 

As previously mentioned, it is possible to sample random 
variates to perform single-system checks on numerous different 
force structures. The data from these single-system checks 
can then be consolidated to develop a single set of failed 
attempts from various different communications systems. Using 
this technique, it is possible to enlarge the set of different 


equipment combinations checked by the program. 


F. SUMMARY 

The measure of effectiveness for the STANAG 4214 protocol 
was defined as the mean percentage of successful calls ina 
random communication system when each formation calls every 


other formation once. Additionally, two methods for isolating 
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failure causes were developed: Graphical Cause Identification 


and a mathematical program. 
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VI. RESULTS 


This chapter will discuss the results obtained from using 
TACFONE-NATO to assist in performing the analyses set forth in 


Chapter V. 


A. RESULTS OF ESTIMATED SUCCESS RATES 

Table 2 consolidates the results of the estimated 
effectiveness of the protocol for a random Communication 
System in terms of percentage of successful calls when each 
formation calls every other formation once and the path is 
randomly chosen when more than one possible path exists. The 
results for the runs without lateral connections were derived 
from 30 randomly generated Communication Systems making a 
total of 2,850,300 simulated calls for each set of rules 
evaluated. 

The lateral connection rules were tested on six randomly 
generated Communication Systems with each formation being 
connected to every other formation (i.e., every possible 
lateral connection was made). The purpose of connecting all 
formations was to put the maximum amount of stress on the 
lateral connection rules, regardless of how unlikely it would 


be for this situation to occur. The test for the lateral 
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TABLE 2 PERCENTAGE OF SUCCESSFUL CALLS. 


Estimated 
Expected Low High 
Success Rate | Estimated Estimated 


Rules Invoked 


Basic STANAG 
(No Anti-Looping 


Basic STANAG 


With Anti-Looping 


Basic STANAG 
With Anti-Looping & 
Numbering Change 


Basic STANAG 

With Anti-Looping, 

Numbering Change & 

Lateral Connections 





connection rules checkei each possible path (based on the 
routing tables) to verify that no possible loops existed. 

Table 2 reveals the tremendous improvement obtained by 
invoking the anti-looping rules set forth earlier. The table 
also shows that the numbering modification, in conjunction 
with the anti-looping rules, appears to eliminate all failed 
calls using the STANAG 4214 protocol. The 100 percent success 
rate for systems with all possible lateral connections also 
demonstrates the effectiveness of the lateral connection rules 
which were imposed on the model. 

It should be noted that Table 2 gives the expected success 
rate for a random communication system. The actual expected 
success rate for a given system may vary significantly from 


these numbers for the basic model and for invoking only the 
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anti-looping rules. It would not vary for the implementation 
of all rules since in this case all systems have a 100 percent 
expected success rate. For instance, a Communication System 
with three or fewer Hosts will have no possible loops. 
Therefore, if no dead-ends were possible, it would have a 100 
percent success rate even without invoking the anti-looping 
rules. On the other hand, a large system with six fully 
connected Hosts would probably have something near the 
observed low 66 percent success rate. 

Since any system randomly generated was regarded equally 
as likely to occur, Table 2 weights each Communication System 
equally in determining the expected success rate for a system. 
This means that a large system making thousands of calls 
resulting in perhaps say, a 70 percent success rate, is 
weighted the same as a small system making only a few dozen 
calls with a 100 percent success rate. In an attempt to 
determine the protocol’s effectiveness for a random single 
call, the total number of calls made and the total number of 
successful calls were also collected for each set of rules 
invoked. These results can be seen in Table 3. 

The 80 percent success rate for the basic model compared 
to the 99.89 percent success rate for the anti-looping rules 
only in Table 3 shows even more clearly that looping is a 
problem which must be dealt with. The 99.89 percent success 


rate for implementing anti-looping rules only, also shows that 
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TABLE 3 EXPECTED SUCCESS RATE FOR A RANDOM CALL 


Estimated 
Success Rate 
Number of | Successful for a Random 
Call 


Basic STANAG 
With Anti-Looping & 
Numbering Change 


Basic STANAG 

With Anti-Looping, 98,622 98,622 100.00 
Numbering Change & 

Lateral Connections 





the only rule discrepancy discovered results from a situation 
which apparently occurs rather infrequently. However, to 
ensure a 100 percent success rate for any possible 
communication system, this problem must too be remedied. It 
is also apparent that the anti-looping heuristic and proposed 
rule change eliminated all failed calls and that the lateral 
connection rules worked flawlessly even under the most arduous 


circumstances. 


B. RESULTS OF FAULT ISOLATION PROGRAM 

The mathematical program discussed in Chapter V was used 
for the basic model (no modifications invoked), the basic 
model with anti-looping (but no other rule modifications), and 
the basic model with anti-looping and a proposed modification 


to the protocol. These results will now be discussed. 
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1. The Basic Model 

By far, the greatest problem encountered in the basic 
model was with looped calls. The list of conclusion variables 
from the mathematical program included only 2yos7, 7... (note 
that Hosts were assumed to be their own parent, hence all 
Hosts were assigned a "T" for NATV). This showed that Host 
formations were the most common (and likely the only) factor 
in looped calls. Hence, anti-looping rules for inter-host 
connections should be sufficient to eliminate looping. 

There was also a problem with dead-end calls. Using 
both the mathematical program and the graphical display, it 
was possible to identify a protocol problem with the numbering 
of duplicate-capuble Secondary formations which have a 
multiple-routing Host and a single-routing Parent (Primary). 
The problem only occurs ‘vier. cnere are other formations from 
the same country in the necwork who do not have the same 
parent, see Figure 18. When this situation occurs, at least 
two of the like-country formations are numbered the same using 
STANAG protocol. This results in ambiguity for the single- 
routing Primary when attempting to route a call to one of 
these like-numbered formations, as one of the two possible 
switch choices does not route to the desired formation, see 
Figure 18. Since the Primary is only single-routing capable, 
there is at least a 50 percent chance (if each possible switch 
is chosen with equal likelihood) that the call will fail. The 


STANAG rule for numbering such Secondaries states: 
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Multiple Route 
Host Germany 
AC: 804 


ingle Router Multiple Route 
Primary UK Hrimary Germany 
AC: 804 AC: 804 


econdary 
uplicate Capable 
France AC: 80 
econdary 
ers 
rance AC: 804 


econdary 
Germany 
AC: 804 





Figure 18 Numbering rule problem. 











If the major host formation and/or the formation under 
direct command are only capable of "single" routing chen 
its secondary formations shall be assigned unique prefixes 

(STANAG 4214, 1985, p.B-6) 

This rule was interpreted to mean that all Secondary 
formations of a single-routing Primary and multiple-routing 
Host must be numbered uniquely amongst themselves. The 
recommended solution to this problem is to have the STANAG 
clearly state that all such formations must be numbered 
uniquely from all other formations in the entire network. 

2. The Model With Anti-Looping Rules Only 

After imposing the anti-looping rules (and lateral 
connection rules) stated previously, no failures were 
encountered due to looping in communication systems even with 
lateral connections. However, the problems with dead-end 
calls persisted. 

3. The Model With Recommended Change to STANAG 4214 

With the implementation of the recommended charge for 
the numbering problem mentioned earlier, along with the use 
anti-looping rules and lateral connection rules, no failures 
of any kind were encountered for numerous randomly generated 


Communication Systems. 


C. SUMMARY 
The results of the success rate analysis and the fault 


isolation analysis reveal that looping is the single most 
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likely cause for failures if it is not dealt with properly. 
Fortunately, the results also show that the proposed anti- 
looping rules work flawlessly in preventing looping. Finally, 
the results also revealed an error in the numbering of 
duplicate-capable Secondaries witha multiple-routing Hert and 
a single-routing Primary. Further analysis showed that the 


recommended rule changes alleviated the numbering problem. 











VII. CONCLUSIONS AND RECOMMENDATIONS 


The primary goals of this study were to test the protocol 
of STANAG 4214, develop anti-looping rules for inter-host 
connections, and develop rules to allow for lateral 
connections within a Communication System without allowing 
looping. To this end the object-oriented, graphical 
simulation model TACFONE-NATO was developed. Through the use 
of this model, in conjunction with a mathematical program 
developed for additional analysis, the following were 
accomplished: 

1. The need for reliable anti-looping rules was verified. 
2. A numbering discrepancy in the STANAG 4214 protocol was 
discovered and isolated. The discrepancy deals with the 
numbering of duplicate-capable Secondaries with a multiple- 


routing H-st and a single-routing Primary. 


3. Recommended anti-looping heuristic, numbering change 
and lateral connection rules were tested and verified. 


In addition, TACFONE-NATO will allow JIEO and other users 
to: 


i. Automatically number (using STANAG 4214 protocol), 
build routing tables for a user-defined Communication 
System and output this information to a user-selected file. 
The program automatically invokes the lateral connection 
rules via the building of the routing tables and can also 
be selected to use the anti-looping heuristic and proposed 
numbering rule change. 


2. Determine the effectiveness of a user defined system 
which has already been numbered. In this case routing 
tables will be built by the model (the use of the anti- 
looping heuristic is determined by the user). 
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3. View a randomly generated system or user-defined system 
graphically. 


The graphical interface developed for TACFONE-NATO makes the 
program simple to run and allows for easy selection of user 
options. 

This analysis of STANAG 4214, which required generating 
over ten million simulated phone calls, reveals that looping 
is a critical problem which must be avoided and that there is 
a flaw in the current protocol. However, this analysis also 
verifies the effectiveness of the protocol when implemented 
with TACFONE-NATO’s anti-looping rules and recommended 
numbering modification. It is recommended that the anti- 
looping heuristic developed for and used in TACFONE-NATO be 
utilized as the means to prevent looping. It is also 
recommended that STANAG 4214 be modified to incorporate the 
suggested rule change. Finally, this analysis also shows that 
lateral connections may be allowed to exist under the rules 
set forth in Chapter V without degrading the protocol’s 


effectiveness. 
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APPENDIX A 
SUBSIDIARY AREA CODES ALLOCATED TO NATIONS 
Nation Number of Master ACs Subsidiary ACs 
Major (Host) 
Formations 

Belgium 2 800 200, 300, 400 
700 

Canada 1 801 201, 301, 401 

Denmark 1 802 202, 302, 402 

France 4 803 818, 203, 218 
703 718, 303, 318 
603 618, 402, 418 
503 

Germany 4 804 819, 204, 219 
704 719, 304, 319 
604 619, 404, 419 
504 

Greece 1? 805 205, 305, 405 

Iceland 1? 806 206, 306, 406 

Italy 3 807 207, 307, 407 
707 
607 

Luxembourg 1? 808 208, 308, 408 

Netherlands 1 809 209, 309, 409 

Norway 1 810 210, 310, 410 

Portugal 1? 811 211, 311, 411 

Turkey 1? 812 212, 312, 412 

UK 2 813 213, 313, 413 

USA 4 814 816, 214, 216 
714 716, 314, 316 
614 616, 414, 416 
514 

NICS 1 815 = 

COMLANDJUT 1 715 315 


Spain Le 817 217, 317, 417 











APPENDIX B 
USER MANUAL FOR TACFONE-NATO 


I. INTRODUCTION 


TACFONE-NATO is designed to simulate the STANAG 4214 
numbering and routing protocol. It is assumed the user has a 
working knowledge of STANAG 4214 and is familiar with the 
terminology used in this document, as well as the thesis on 
this subject. TACFONE-NATO simulates a communication system’s 
crucial elements in order to allow the implementation of the 
STANAG 4214 protocols. The entire model was designed to 
represent the physical equipment and the actual process of 
sending and receiving calls, but only at the level of fidelity 
for each element that was required for this study. Therefore, 
some elements that are modeled may not exactly reflect the 
actual equipment/process, but for the purposes of testing the 
STANAG or a different numbering system, it reflects accurately 
the portion affecting the numbering of formations and routing 
of calls. The model is completely supported with graphics, 
which allows for ease of use and simplifies the analysis of 
results. 

The information in this users’s manual is presented in the 
following format: 

Chapter I Introduction, Definitions, and Overview 


Chapter II Session using TACFONE-NATO 
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Chapter III Input Files 


Chapter IV Output Files. 


A. BASIC MODEL OBJECTS 

What follows is a description of the basic building blocks 
of TACFONE-NATO. As discussed previously, these are the 
crucial elements of a communication system required to 
evaluate of the STANAG 4214 protocol. 

1. Communication System 

The communication system consists of a set of networks 

that are connected only through the Host formations. These 
networks are connected in such a way to comprise a connected 
graph of all networks and may be comprised up to a fully 
connected graph. 

2. Networks 

A network is a hierarchically constructed tree of 

formations with a maximum of three levels, called Host, 
Primary, and Secondary. The only connections allowed between 
formations in a network are the ones that follow this tree 
structure. Therefore, under current STANAG 4214 protocol, the 
Secondary formations only have one connection, which is with 
their parent (Primary) formation. The Primary formations have 
one connection with each of their children (Secondaries) and 
one connection with their Host formation. Each Host formation 


has one connection with each of his child Primary formations 
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and connections to other Host formations, depending on the 
topology of the communication system. 
3. Formations 
The formations represent the communication systems for 
different sized military units. Generally, Host level 
formations represent Corps-sized units, Primary level 
formations equate to division-sized units and Secondary level 
formecions represent brigade-sized units. The STANAG 4214 
protocol does not address units of any smaller size, 
therefore, TACFONE-NATO does not represent any other unit 
types. 
4. Switches, Trunks and Gateways 
These elements are modeled to reflect definitions as 
described in STANAG 4214. 
B. NUMBERING THE COMMUNICATIONS SYSTEM 
The model numbers the Communications System according to 
the rules of the STANAG 4214 with the exception of options to 


be discussed in later sections. 





C. GENERATION OF COMMUNICATION SYSTEMS 

TACFONE-NATO will either read in a user-defined force 
structure, or randomly generate a force structure. If the 
force is user-defined, TACFONE-NATO can automatically number 
the communication system, or the NIACs can be defined by the 
user. This gives the user the flexibility to analyze a 
proposed numbering scheme that does not follow the STANAG 


rules. The connections between networks at the Host level are 
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either randomly generated by TACFONE-NATO or defined by the 
user. When the communication system is generated randomly, 
the number of networks, formations, and connections between 
networks are all randomly determined from preset bounds. The 
identity of the formations, including nationality, are also 
randomly determined from the existing units that are available 
to NATO. Once the force has been generated and connected, the 
formations are numbered using the method previously discussed. 

When the program automatically numbers a user-defined 
force structure it is possible that a Host nation mat not have 
enough subsidiary area codes assigned to it. If this occurs, 
the program will halt and inform the user which nation 
requires more subsidiary area codes. Adding of area codes can 
be done by modifying the "AREACODE.DAT" file, see chapter 
three, INPUT FILES, for further information on how to modify 
this file. 
D. BUILDING OF ROUTING TABL&S 

Once the communication system is generated and has been 
numbered, the routing tables are initialized for each trunk of 
each formation. Each network first updates its routing tables 
internally, then the switches connecting the networks 
initialize their routing tables. The basic model allows all 
paths that exist from one network to another to be reflected 
in the routing tables. The STANAG 4214 does not directly 
address what paths should exist from one network to another, 


only that it is done in a way "to prevent looping". The basic 
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model operates this way to give the ability to measure the 
effectiveness of anti-looping rules which were added tc the 
model. 
E. GENERATING AND ROUTING CALLS 

Calls are generated from every formation to every other 
formation. The formation routes a call based on the physical 
limitations of communications equipment of its nation, as well 
as the contents of its switches’ routing tables. Between 
networks, calls are only routed via one path (single-routed). 
The call tracks all formations that it is routed through to 
reach its destination. Calls are not allowed to be routed 
immediately back along a trunk just used to reflect the actual 
physical limitations. 
F. GRAPHICS 

The TACFONE-NATO model utilizes the SIMGRAPHICS (MODSIM 
93) portion of MODSIM to display all input and output 
graphically. The model is controlled through the use of 
graphical user interfaces, all mouse-driven. This eases the 
use of TACFONE-NATO dramatically, by making it much more user- 
friendly. The Communication System is displayed on the screen 
graphically using a separate window for each network. Each 


formation is displayed as a rectangle with its nationality, 


unit size (corps, division, or brigade), unit number, and 
NIAC. All trunks are represented as lines between the 
formations. The Host formations are also displayed in a 


separate window with their inter-host connections also 
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displayed as lines. When calls are being routed, the 


originator formation and the destination formation are 
uniquely colored and all trunks in the path are also colored 
to allow the user to visually watch the calls be routed. The 
display is frozen when a failed call occurs, which aids in the 


trouble shooting of any protocol problems. 
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II. A SESSION USING TACFONE-NATO 


Figure 1 below shows the basic flow for a run of TACFONE- 
NATO. The specifics of each of these steps will be discussed 


in more detail throughout the remainder of this Chapter. 


“Comm System 
Capabiites 


At | eee eee oy 


{ Output Desired acca 
poet Desired Output ee | Enter Fie Name(s} 


User Determined Number Qt 
Select Run Type Simm Systems Enter Number 


[Select Rule Changes} 
Desired 


[ Select Method of Read In [ Select Numbering | 
—eeEeEeEeEeEeEEE | ; 
{ Method 


Generaton 
| Enter FileName. 
Sk Se in 
| paler joa Enter File Name 








Figure 1 System flow for a run of TACFONE-NATO. 


To start the program type TACFONE at the command line in 
the directory where the executable file and all input files 
are stored. The first option presented is how to set the 
random number generator seeds: automatically or manually, see 


Figure 2. 
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To pick the option 


desired, click the Tet ancaln.Sbed Random Number Generator. 
Manually Enter Random Number Generator Seeds | 


appropriate button with the 
Click here when choice is complete } 


mouse and then click the 





Figure 2: Random Number 
"click here when choice is Generator Seed Choice Box. 


complete" button to move on. 

The random number generator is used when randomly generating 
a communication system and when the calls are being routed. 
If the same seeds for the generators are used for two separate 
runs, the exact same results will be produced (all other 
options consistent). The seeds will be set to the same preset 
numbers every time the automatic seeding is chosen. It is 
possible to view different randomly generated systems by 
choosing to manually enter different seeds. 

When the manual method for setting the random generator 
seeds is chosen, the screen snown in Figure 3 will be 
displayed. There are five 
random number generators 
utilized by TACFONE-NATO, 

. Seed 1 1 
which means five seeds are Seed 2 1 
required to be set. To enter Seed 3 1 
a number (seed), place the [ff Seed 4 1 
mouse cursor on the desired Seed 5 , | 


line and type in the number. Click here when done 


Ensure there are no spaces! Figure 3 Random Number 
Generator Seed Entry Box. 





To switch to another line, 
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use the mouse or the arrow keys. Once all numbers have been 


entered, click the "click here when done" button with the 
mouse. The next option presented is whether or not the 
duplicate-capable, and single/multiple-router information for 
each country’s communications equipment will be read in (to 
reflect actual capabilities) or be randomly generated by 
TACFONE-NATO (to allow for more robust testing of the rules). 
Two choices must be made on 


this screen, one for each 


u f poise ( ‘Rengorly Generate Duplicate Capable information 
YPS - Papert sseys iad | Read in Duplicate Capable information From a fil 


Multiple Router information 


Figure 4 for the actual ue 
g i Read In Single/Mul tiple Router Information From a file | 





screen). Once the choices 
Click here when done making choices } 





. t " " . 
are made, click the "click Figure 4 Equipment 


ghen. dane! button with che Characteristics Choice Box. 


mouse. 
If either of the options 


to read in capabilities from NDC.DAT 


Fs ets ere selected, Click here when file name is entered J 





Figure(s) 5 and/or 6 will be 


Figure 5 Duplicate Capable 
Information File Name Box. 


displayed, depending on the 
selections. Enter the appropriate file name(s) on the line by 
clicking on the line and typing the name from the keyboard. 
Once the file name is entered, click the "click here when file 


name is entered" button with the mouse. 
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The next screen allows 


for the selection of what ROUTING DAT 


type of run is to. be Click here when file name is entered ) 





conducted, see Figure 7 for 


Figure 6 Single Router 
Information File Name Box. 


an example of this choice. 


The choices are defined 


Cakulate Percent Successful Calts(Minimum 900 Runs) 


as: User Determined Number of Comm Systems 
g(orje ron ewumperates Alf possibie cai! paths) 


Determine Numbering and Routing Tables of a Read in System 


Click here when type of run has been chosen © 





1. Calculate percent 
successful Calls. ae 
This option requires a Figure 7 Type Of Run Choice 
minimum of 900 runs Box. 
and approximately 25 
hours to complete. 

The run randomly generates a communication system and 
generates calls from each formation to every other 
formation using only one path to reach it’s 
destination, calculating the percentage of successful 
calls. The calis are then regenerated at least 30 
times until the 95 percent confidence interval for 
percentage of successful calls is within 10 percent of 
the estimated mean. The same is done for at least 30 
different communication systems to estimate the 
expected success rate for a random system. Once 
complete, the statistical data is printed in the 
output file designated by the user. 





2. User determined number of communication systems to be 
user defined or randomly generated. Calls will be 
made from every formation to every other formation 
utilizing only one path to route the call. Dependent 
on the size of the system and number of failed calls 
the amount of time required is approximately 2-45 
minutes for each communication system. 


3. Complete fault checking of a user defined or randomly 
generated communication system. Calls will be 
generated from every formation to every other 
formation utilizing all routes possible to determine 
if there are any potential failures in the 
communication system based on it’s numbering and the 
routing table configurations. If there are any 
failures the attributes of the suspected formations 
which may have caused the failure are printed in 
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various files. The file names are printed on the 
screen at the end of the run. The time required for 
each communication system is approximately twice as 
much as option two. 

4. Number a user defined communication system. This 
option will take the user defined communication system 
and determine the numbering of all the formations and 
the routing table configurations for each switch. The 
user can graphically view the system with the graphics 
option, but no calls will be simulated with this 
option. This option will require less than two 
minutes. 

Option 1 allows the user to determine the expected 
operational effectiveness of a set of rules. Option 2 allows 
the user to look at communication system(s) to see the set-up 
or generate complete information of that system. Option 3 
completely checks a system for any faulting numbering and will 
help isolate the faults. Option 4 will quickly number a pre- 
defined system. Select the desired option by clicking on the 
appropriate button with the mouse and then clicking the "done” 
button. If "user determined number of communication systems" 


is selected, the next screen 


will ask for the number of 


Number of Comm Systems , 1 


systems to be generated, see 


Click here when number is entered ) 
Figure 8. Enter the number 





Figure 8 Number of 


by clicking on the line, Communication Systems Box. 


typing in the number from the 
keyboard, and then clicking on the "click here when the number 


is entered" button with the mouse. 
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The next screen offers the options on the hard copy output 


of the communication system(s), see Figure 9: 


1. Generate full comm 
system information 
output. This option 
will generate the 
fol lowing information “DONOT Cencrate Conn SniembifaminarOuteur 
for each formation: OR re se one 

-country Click here when choice is made : 

-unit type(Corps, 

Division, Brigade) Figure 9 Type of Output Choice 

-unit number Box. 

-unit’s assigned NIAC 

-~single or multiple-router 

-duplicate-capable or not 

-formation’s parent. 
For each switch of each formation the following 
information is provided: 

-the formation connected to the other end of the 

trunk 

-the numbers in the incoming and outgoing routing 

tables determined via the rules the user selects. 
Also, for each network: 

-summary listing of the area codes assigned to that 

network is given. 





2. Generate numbering only. This option gives an 
abbreviated version of the previous listed option. 
The following information is given for each formation: 

-country 
-unit type 
-unit number 
-NIAC assigned 
The following information is given for each switch: 
-the formation connected to the other end of the 
trunk 
-the numbers in the outgoing routing table. 


3. Do not generate Comm System information Output. This 
option results in no output file containing 
information on the physical configuration of the 
communication system. 

The full output option gives all possible pertinent 


information about the communication system for trouble 


shooting purposes. The numbering only option outputs only 
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the information necessary to 
number each formation and 


set up all routing tables. 





If either of the two 


Figure 10 Output File Name 
types of output is Box. 


requested, the next screen will ask for the name of the file 
to which the output will be written, see Figure 10. The 
procedure for entering the file name is the same as for 
previous files. The format of the output files is discussed 
in Chapter IV, OUTPUT FILES. 

The next screen asks if statistical output is desired or 
not. The choice is made in the manner discussed earlier for 
general output. When statistical output is chosen the 
following information is provided for each communication 
system: the number of the communication system, number of 
calls made, number of successful calls, number of failed 
calls, and the percentage of successful calls. If more than 
one communication system is simulated, the same information 
is given for all communication systems totaled. A 95 percent 
confidence interval for the estimate of the mean success 
rate is also given. If statistical output is chosen, the 
next screen will request the name to which this output will 
be written. The file name is entered in the same way as for 
previous files. 

The next screen asks whether or not to use the rule 


modification to STANAG 4214 which corrects an error 
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discovered in the protocol, 
see Figure 11. The choice 
is made in the same way as 


for previous selections. 


The following screen 
gives the chcice of whether 
to utilize the anti-looping 
rules developed for TACFONE- 
NATO, see Figure 12. The 
anti-looping choice will 
institute an anti-looping 
heuristic which allows for 
maximum redundancy between 
the Host formations while 


preventing looping. 


table configurations. 


DO NOT Use STANAG Ru ie change | 


Click here when choice is made j 
STANAG Rule Change 





Figure 11 
Choice Box. 





Use Anti- ping Rules 


DO NOT Use anitospina Ru les | 


Click here when choice is made } 





Figure 12 Anti-Looping Rule 


Choice Box. 


This is implemented through the routing 


The next option presented is how the communication 


system(s) is (are) to be 


generated: randomly by 
TACFONE-NATO, or by reading 
in a user defined 
communication system from a 
file, 


see Figure 13. The 


format for the user defined 


ndomly Genérate Comm System 


‘Read In Comm System from file | 


Click here when choice is complete } 





Figure 13 Communication System 
Generation Choice Box. 
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communication system file is discussed in Chapter III, INPUT 
FILES. 

If the communication system is to be read in froma 
file, a choice of how formations are to be numbered is 
provided. The choices are: manually from the communication 
system file defined by the 


user, or automatically by = 


TACFONE-NATO utilizing the Automatically number formations | 


STANAG 4214 protocol and the Click here when numbering choice is complete } 





other options selected Figure 14 Formation Numbering 


; ; Choice Box. 
earlier, see Figure 14. The 


choice is made in the way as for previous selections. The 
reading in of user defined numbers allows for the testing of 
a numbering scheme that may not follow the exact protocol of 
the STANAG. If the "read comm system from file" option is 
selected, the program will request the file containing the 
communication system information. 

The next choice for a communication system being read in 
from a file is whether to 


read connections for the 


ead Conner ane foc Care Stem fom Fle 


PRR etd 


Randomly Generate Connections (only at Host level). | 
_Click here when choice is made ) 


Figure 15 Connection Choice 
Figure 15. The option for Box. 


system in from a file or for 


TACFONE-NATO to generate the 





connections randomly, see 


reading the connections in from a file allows the user to 


define exact inter-host connections and also lateral 
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connections which TACFONE-NATO does not generate randomly 
(all parent-child connections are always constructed by 
default). 

The model automatically institutes a method of updating 
the switches’ routing tables that will not allow looping to 
occur with lateral connections. The option of randomly 
generating the connections will result in connections 
between the Host formations only, as prescribed by the 
STANAG 4214 protocol. If connections are to be read in, the 
program will ask for the name of the file containing the 
connections data, see Figure 
16. The format for this 
file is discussed in Chapter SONNECT.DAT 


III, INPUT FILES. 


Click here when file name has been entered | 





AG Ehee Petits sages “en Figure 16 Connection File Name 


the initial options chosen, Box. 


TACFONE-NATO commences the run. All runs present a window 
containing two level meters that track the real time 
percentage of calls made and percentage of calls successful 
to that point. If graphics were chosen, the communication 
system and the routing of calls will be displayed on the 
screen as previously discussed. For the user determined 
number of communication systems option, once the system is 
generated and drawn, the option to generate calls for the 
current system or to continue on to the next system is 


presented, see Figure 17. This option is provided if the 
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user wishes to only observe the communication system set up 
and then move on to the next system. In either case, any 
windows can be resized at this point by clicking and 
dragging the corner. Once the inspection of the system is 
complete, a click on the appropriate choice for generating 
or not generating calls is made. 

If calls are to be a 
generated for the system, a “Generate Cails for this Comm System 

DO NOT Generate Calls GO to Next Comm System - 


"Start making calls" button 
Click here when choice is made 





will be presented, see — 
Figure 17 Generate Calls Fcr 

Figure 18. This allows for This Comm System Box. 

an additional opportunity to 


resize any windows prior to 








“8 


Click here to start making calis ; 


Figure 18 Start Making Calls 
For System Button. 


calls being generated. 

Once calls are started, 
the windows will not resize 
until either a call fails or 
the calls are completed. If a failed call occurs, any 
window can be resized to allow for closer inspection of the 
situation which caused the failure. Once the inspection is 
complete, a simple mouse click in the "continue" box, will 
resume the run. 

Upon completion of all calls, a button is displayed to 
"remove this communication system", see Figure 19. This 
allows the user to inspect the system graphically prior to 


either moving to the next system or completing the model 
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run. If more then one 


communication system is to Click here toremove this Comm Systen | 


be generat.d, the user will Figure 19 Remove Thae. Conn 
System Box. 





be presented with the option 
of making calls for each system as they are generated and 
drawn on the screen. Upon completion of calls for the last 
communication system, the requested output is written to the 
appropriate files. The user can then print out these files 
when desired. The format for the output files is discussed 


in Chapter IV, OUTPUT FILES. 
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III. INPUT FILES 


Figure 20 summarizes all possible input files used by 
TACFONE-NATO. Formats for these files will be discussed 
separately. 

REQUIRED FILES : 


AREACODE.DAT--lists subsidiary area codes for each 
nation. 


UNIT.DAT --lists units available from each nation. 


OPTIONAL FILES (named as desired): 


Routing Capabilities--lists whether each nation’s 
communications equipment is 
single or multiple-routing 


capable. 


Duplicate Capability--lists whether each nation’s 
communications equipment is 
duplicate-capable or not. 


CommSystem Data --lists the units of a manually 
generated CommSystem. 


Connection Data --lists the connections of a 
manually generated CommSystem. 





Figure 20 Input file types. 


A. FILES REQUIRED FOR ALL RUNS 

There are two files required for the TACFONE-NATO 
simulation model to work regardless of the type of run 
desired. These files are "AREACODE.DAT" and "UNIT.DAT". The 


names of these files are not negotiable and must be exactly as 
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appears above. The AREACODE.DAT file contains all subsidiary 
area codes assigned to each nation as per STANAG 4214. The 
UNIT.DAT file contains information regarding the number of 
each type of unit available from each nation in assembling a 
NATO force. The exact format of each file will now be 
discussed separately. 
1. Format For AREACODE.DAT File 
The basic format for this file is: 


1. A header line at the top of the file (exact wording 
not critical). 


2. A single line for each nation which delineates the 
area codes for that nation. The format for each line 
is: 

Name of nation, XXX XXX XXX 0; 

where the XXX's represent subsidiary area codes and the 
0 is the last entry on the line. The nations must be 
listed in the same order as they appear in STANAG 4214, 

see Figure 21. 
As noted, the order of nations must be as in Figure 
21. The spelling, including capitalization, for each nation 
must be exactly as in Figure 21. The exact order of the 
numbers for each nation is not critical, but it should be 
noted that those numbers appearing first in the lists will be 
the first ones used. The 0 at the end of each line is 
critical as it denotes the end of subsidiary area codes for a 
particular nation. It is not permissible to exclude a country 
from the list if it has no subsidiary area codes. Instead, 


simply put a 0 as the only entry in its list of subsidiary 


area codes (see NatoComm in Figure 21). The list in Figure 21 
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Subsidiary Area Codes for Each Nation 

Belgium 200 300 400 0 

Canada 201 301 401 0 

Denmark 202 302 402 0 

France 818 203 218 718 303 318 618 403 418 0 
Germany 819 204 219 719 304 313 619 404 419 Q 
Greece 205 305 405 0 
Iceland 206 306 406 0 
Italy 207 307 407 O 
Luxembourg 208 308 408 0 
Netherlands 209 309 409 0 
Norway 210 310 410 0 
Portugal 211 311 411 0 
Turkey 212 312 412 0 
UnitedKingdom 313 413 0 
UnitedStates 214 216 7 
NatoComm 

ComLandJut 0 

Spain 317 417 


16 314 316 616 414 416 0 





Figure 21 Example of AREACODE.DAT file format. 


denotes the assignments made in STANAG 4214. These numbers 
may be changed without adversely affecting the model. 
2. Format For UNIT.DAT File 
The UNIT.DAT file determines the pool of units 
available for the model to draw from when randomly generating 
force structures. The basic format for this file is: 


1. A header line at the top of the file (exact wording 
not critical). 


2. A single line for each nation which delineates the 
number of each type of unit available for force 
construction from that nation. The format for each line 
is: 

Name of nation, X1 X2 X3; 
where the Xl represents the number of corps available, 
X2 represents the number of divisions available, and X3 


represents the number of brigades available. X3 is the 
last entry for a line. The nations must be listed in 
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the same order as they appear in STANAG 4214. See 
Figure 22. 


or each country 


Belgium 
Canada 
Denmark 
France 
Germany 
Greece 
Iceland 
Italy 
Luxembourg 
Netherlands 
Norway 
Portugal 
Turkey 
UnitedKingdom 
UnitedStates 
NatoComm 
ComLandJut 
Spain 


a] 


PRP BNP HEEB EPH HEP EP eR PEND 
WOONKDWWWWWWW 


WwoODOONnWDWWWHWUWUWWW WY 





Figure 22 Example of UNIT.DAT file format. 


The order of nations must be as in Figure 22. The 
spelling, including capitalization, for each nation must be 
exactly as in Figure 22. It is not permissible to exclude a 
country from the list if you do not wish it to have any units 
available. Instead, simply put in 0’s for the number of 
Corps, Divisions, and Brigades available for that nation. 
Changing the numbers in this file will only change the 
relative likelihood of randomly choosing units from any 
particular nation when randomly generating a CommSystem. 

WARNING: When randomly generating a communication 
system, the model replaces any unit which requires a Host to 


be assigned a new subsidiary area code when the Host nation 
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has no more subsidiary area codes to be assigned. This means 
that it is possible for the program to go into an infinite 
loop in search of a unit which does not create this 
requirement if no such unit exists. Therefore, it is 
advisable to maintain a relatively wide variety of units 
available from the different nations. 
B. FILES REQUIRED FOR MANUAL INPUT 

Additional files may be required if it is desired to 
manually enter data defining some or all of the aspects of the 
communication system to be analyzed. These files are not 
required if these data are to be randomly generated. The 
formats for these additional files will now be discussed. 

1. List of Routing Capability for each Nation 

If desired, the routing capability (single-routing or 

multiple-routing) for each nation’s communications equipment 
can be read in froma file. This file may be named as desired 
since the program will ask for the name of the file to be 
read. The default filename is "ROUTING.DAT". The basic 
format for this file is: 


1. A header line at the top of the file (exact wording 
not critical). 


2. A single line for each nation which delineates whether 
that nation’s communications equipment is single-routing 
capable. The format for each line is: 


Name of nation, BOOLEAN; 
where BOOLEAN represents either a "True" (single- 
routing) or "False" (multiple-routing) entry. The 


nations must be listed in the same order as they appear 
in STANAG 4214. See Figure 23. 
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Country Single Routing 
Belgium True 
Canada False 
Denmark True 
France False 
Germany True 
Greece True 
Iceland True 
Italy False 
Luxembourg False 
Netherlands True 
Norway True 
Portugal True 
Turkey False 
UnitedKingdom False 
UnitedStates False 
NatoComm False 
ComLandJut True 
Spain True 





Figure 23 Example of Routing data file format. 


Again, the order of nations must be as in Figure 21. 
The spelling, including capitalization, for each nation «ust 
be exactly as in Figure 23. The spelling of "True" and 
"False" must also be as in Figure 23. It is not permissible 
to exclude a country from the list, an assignment of "True" or 
"False" must be made for each nation. 

2. List of Duplicate-Capability for each Nation 

If desired, the duplicate-capability (duplicate- 
capable or not duplicate-capable) for each nation’s 
communications equipment may also be read in from a file. 
This file may be named as desired since the program will ask 
for the name of file to be read. The default filename is 


"NDC.DAT". The basic format for this rile is the same as for 
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routing capability except that a "True" entry represents not 
duplicate-capable and a "False" entry represents duplicate- 
capable, see Figure 24. All comments made about the Routing 
data file also apply to the not duplicate-capable data file as 
well. 


Country Not Duplicate Capable (T=NotDupCap, F=DupCap 
Belgium False 
Canada False 
Denmark True 
France True 
Germany False 
Greece False 
Iceland False 
Italy False 
Luxembourg False 
Netherlands True 
Norway False 
Portugal False 
Turkey False 
UnitedKingdom False 
UnitedStates True 
NatoComm False 
ComLandJut True 
Spain False 


Figure 24 Example of Not Duplicate Capable file format. 


3. Manually Generated CommSystem 
If desired, a manually generated CommSystem may be 

entered for full analysis or for just numbering and setting up 
routing tables. A file containing a manually generated 
CommSystem may be given any name desired since the name of the 
file to be read will be asked for by the program. 

The default filename is "NETWORK.DAT". The format for a 
manually generated CommSystem is: 


1. A header line at the top of the file (exact wording 
not critical). 











"EndOfData". 


2. A single line for each unit in the CommSystem. The 

format for each line is: 
Level, Country, UnitType, UnitNumber, XXX; 

where XXX is the area code for that unit if it is 
desired to not have the model automatically number the 
system. The units are entered in depth-first order: 
Hostl, Primaryl for Hostl, Secondaryl for Primaryl of 
Hostl, ., SecondaryN for Primaryl of Hostl, Primary2 
for Hostl1, all Secondaries of Primary2 for Hosti, ..., 
PrimaryK for Host1, all Secondaries of PrimaryK for 
Host1; Host2, 

3. A line containing the string: 


Figure 25 illustrates the proper basic format and 
Figures 26 and 27 show the CommSystem it represents. 


Primary 
Secondary 
Secondary 
Primary 
Secondary 


Primary 
Host 
Primary 


Country 
UnitedStates 
UnitedStates 
Germany 
Germany 
France 
Belgium 
Germany 
Germany 
Italy 


UnitType 
Corps 
Division 
Brigade 
Brigade 
Division 
Brigade 
Division 
Corps 
Division 


per AreaCode 


Division 
Brigade 


Primary 
Secondary 
EndOfData 


Portugal 
Luxembourg 





Figure 25 Example of format for reading in a CommSystem. 


There is no limit to the number of Primaries may be 
assigned to a Host or Secondaries to a Primary. The spelling 
of all words is critical however. "Host", "Primary" and 
"Secondary" must be spelled and capitalized as shown; the 


countries must be spelled and capitalized as shown in the 
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Figure 26 Network 2. 





Figure 27 Network 1. 


AREACODE.DAT file example (Figure 21), and the spellings for 
"Corps", "Division", and "Brigade" follow suit. There are no 
allowed unit types other than "Corps", "Division", and 
"Brigade". The only restriction on unit numbers is that they 
must be an unique integer entry. An area code must be 
assigned even if the program is going to automatically number. 
It is recommended to simply enter 0 for the area code in this 
case. All data in the file after the "EndOfData" line will be 


ignored. 
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4. Manually Connecting a CommSystem 

If desired, when a CommSystem is manually generated, 
the exact connections between Hosts may be manually entered 
through a file, rather that have the program randomly generate 
them. This input file also allows for the insertion of 
lateral connections. NOTE: All formations will automatically 
be connected to their parent/children so it is not necessary 
to put these connections in the file. Only enter inter-host 
and lateral connections. A file containing the connections 
for a manually generated CommSystem may be given any name 
desired since it will be asked for by the program. The 
default filename is "CONNECT.DAT". The format for a manually 
connections is: 


1. A header line at the top of the file (exact wording 
not critical). 


2. A single line for each connection desired. The format 
for each line is: 


Countryl, UnitKind1l, UnitNumberl1, Country2, UnitKind2, 
UnitNumber2; 


where the first three entries identify one of the units 
to connect and the second three identify the second unit 
to connect. Figure 28 illustrates the proper basic 
format. 


3. A line containing the string "EndOfData". 


Again, spelling of all words is critical and must be 
as previously mentioned. There is no limit to the number of 


connections which can be made. The program will not connect 
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Countryl UnitKind1l Numl Country2 UnitKind2 Num2 
UnitedStates Corps 2 Germany Corps 3 
Italy Division 1 Portugal Division 3 
Germany Brigade 10 Germany Brigade 11 
EndOfData 





Figure 28 Example of format for reading in connections. 


two units more than once although an attempt to do so will not 
harm the program. If an attempt is made to connect a unit to 
itself or to a unit which does not exist (existing units can 
be obtained from the file containing the read in CommSystem) , 
the program will notify the user of the problem and terminate 
execution. It is the user’s responsibility to ensure that the 
Hosts are connected so as to comprise at least a minimum 
spanning tree. Failure to do this will result in numerous 


failed (dead-end) calls. 
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Iv. OUTPUT FILES 





There are two types of output files that can be chosen in 
the initial options menus. Both options will have a header 
that appears as follows: 

"This output was generated on: Mon Aug 4 09:15:15 1993". 

The date and time will allow the user to identify different 
runs that may have similar force structures. The first option 
of generating full communication system output lists the 
information discussed pieviously in the format shown in Figure 


29. 


Information For Networ 

Formation Number 1 

Formation Level: Host 

Country: UnitedStates Unit Kind: Corps Unit Number: 2 
Not Duplicate Capable Multiple Routing 

National Identifier: 914 Area Code: 604 NIAC: 904604 
External Switch 1 is connected to: 

Country: Germany Unit Kind: Corps Unit Number: 3 
National Identifier: 904 Area Code: 604 NIAC: 904604 
The outgoing routing table contains the following numbers: 
604 819 204 

The incoming routing table contains the following numbers: 
714 816 214 

Internal Switch 1 is connected to: 

Country: France Unit Kind: Division Unit Number: 4 
National Identifier: 903 Area Code: 714 NIAC: 903714 
The outgoing routing table contains the following numbers: 
903714 900714 917816 

The incoming routing table contains the following numbers: 
914714 904816 904214 904714 604 819 204 





Figure 29 Full Communication System information output 











The same information is given for each formation in the 


communication system. The external switches are switches 
connecting the formation to formation in another network. The 
internal switches connect the formation to a formation within 
it’s network. 

The option for numbering information only gives an 
abbreviated version of Figure 29, the information on 
communication equipment capabilities and incoming routing 
tables is not given. The switch information is no longer 
displayed as external and internal, just a listing of the 
switches, what formation it is connected to and the outgoing 
routing table contents. An example of this output can be seen 
in Figure 30. 

The Statistical output lists the options chosen for the 
use of anti-looping rules(or not), the use of the STANAG 


numbering rule change and the type of run at the top of the 


Information For Network 1 

Formation Number 1 

Formation Level: Host 

Country: UnitedStates Unit Kind: Corps Unit Number: 2 
National Identifier: 9i4 Area Code: 604 NIAC: 904604 
Switch 1 is connected to: 

Country: Germany Unit Kind: Coros Unit Number: 3 


The outgoing routing table contains the following numbers: 
604 819 204 

Switch 2 is connected to: 

Country: France Unit Kind: Division Unit Number: 4 

The outgoing routing table contains the following numbers: 
903714 900714 917816 





Figure 30 Numbering only information output. 
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output file. The information provided from each run is the 
communication system number, the run number, the number of 
calls made, number of successful calls, number of failures, 
and the success rate. The same information is provided for 
the totals of each communication system and the total of all 
communication systems. The estimated mean percent successful 
calls, estimated variance and the 95 percent confidence 
interval are also provided at the top of the output when the 
type of run is "calculate percent successful calls". Figure 


31 is an example of this output file. 
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Numbering change implemented. 
Only one path checked for each call. 


Estimated percent successful for a CommSystem = 90.52407 
Estimated Variance of average percent successful = 153.82617 
Ninety-five percent Confidence Interval = 
(86.087169,94.963644) 

List of results for each run: 


Run Calls Successes Failures 


5852 4075 1777 
5852 4185 1667 


30 29 4970 3950 
30 39 4970 3992 
ist of results for each CommSystem: 


CommSystem Runs Calls Successes Failures Success Rate 
Zt 30 175560 123025 52535 70.08 


30 30 149100 118465 


otal results: 


CommSystems Calls Successes Failures Success Rate 
1 2850300 2287056 563244 80.24 


Figure 31 Statistical output. 
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